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Abstract 


The Resource Reservation Protocol (RSVP) can be used to make end-to- 
end resource reservations in an IP network in order to guarantee the 


quality of service required by certain flows.  RSVP assumes that both 
the data sender and receiver of a given flow take part in RSVP 
Signaling. Yet, there are use cases where resource reservation is 


required, but the receiver, the sender, or both, is not RSVP-capable. 
This document presents RSVP proxy behaviors allowing RSVP routers to 
initiate or terminate RSVP signaling on behalf of a receiver or a 
sender that is not RSVP-capable. This allows resource reservations 
to be established on a critical subset of the end-to-end path. This 
document reviews conceptual approaches for deploying RSVP proxies and 
discusses how RSVP reservations can be synchronized with application 
requirements, despite the sender, receiver, or both not participating 
in RSVP. This document also points out where extensions to RSVP (or 
to other protocols) may be needed for deployment of a given RSVP 
proxy approach. However, such extensions are outside the scope of 
this document. Finally, practical use cases for RSVP proxy are 
described. 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5945. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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Introduction 


Guaranteed Quality of Service (QoS) for some applications with tight 
requirements (such as voice or video) may be achieved by reserving 
resources in each node on the end-to-end path. The main IETF 
protocol for these resource reservations is the Resource Reservation 
Protocol (RSVP), as specified in [RFC2205]. RSVP does not require 
that all intermediate nodes support RSVP; however, it assumes that 
both the sender and the receiver of the data flow support RSVP. 
There are environments where it would be useful to be able to reserve 
resources for a flow on at least a subset of the flow path even when 
the sender or the receiver (or both) is not RSVP-capable (for 
example, from the sender to the network edge, or from edge to edge, 
or from the network edge to the receiver). 
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Since the data sender or receiver may be unaware of RSVP, there are 
two types of RSVP proxies. When the sender is not using RSVP, an 
entity in the network must operate on behalf of the data sender, and 
in particular, generate RSVP Path messages, and eventually receive, 
process, and sink Resv messages. We refer to this entity as the RSVP 
Sender Proxy. When the receiver is not using RSVP, an entity in the 
network must receive Path messages sent by a data sender (or by an 
RSVP Sender Proxy), sink those, and return Resv messages on behalf of 
the data receiver(s). We refer to this entity as the RSVP Receiver 
Proxy. The RSVP proxies need to be on the data path in order to 
establish the RSVP reservation; note, however, that some of the 
approaches described in this document allow the RSVP proxies to be 
controlled/triggered by an off-path entity. 


The flow sender and receiver generally have at least some (if not 
full) awareness of the application producing or consuming that flow. 
Hence, the sender and receiver are in a natural position to 
synchronize the establishment, maintenance, and teardown of the RSVP 
reservation with the application requirements. Similarly, they are 
in a natural position to determine the characteristics of the 
reservation (bandwidth, QoS service, etc.) that best match the 
application requirements. For example, before completing the 
establishment of a multimedia session, the endpoints may decide to 
establish RSVP reservations for the corresponding flows. Similarly, 
when the multimedia session is torn down, the endpoints may decide to 
tear down the corresponding RSVP reservations. For instance, 
[RFC3312] discusses how RSVP reservations can be very tightly 
synchronized by endpoints that uses the Session Initiation Protocol 
(SIP) ([RFC3261]) for session control. 


When RSVP reservation establishment, maintenance, and teardown are to 
be handled by RSVP proxies on behalf of an RSVP sender or receiver, a 
key challenge for the RSVP proxy is to determine when the RSVP 
reservations need to be established, maintained, and torn down, and 
to determine what the characteristics are (bandwidth, QoS, etc.) of 
the required RSVP reservations matching the application requirements. 
We refer to this problem as the synchronization of RSVP reservations 
with application-level requirements. 


The IETF Next Steps in Signaling (NSIS) working group has specified a 
new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol 
(NSLP) ([RFC5974]). This protocol also includes the notion of proxy 
operation, and terminating QoS signaling on nodes that are not the 
actual data senders or receivers (see Section 4.8, "Proxy Mode", of 
[RFC5974]. This is the same concept as the proxy operation for RSVP 
discussed in this document. One difference, though, is that the NSIS 
framework does not consider multicast resource reservations, which 
RSVP provides today. 
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Section 2 introduces the notion of RSVP Sender Proxy and RSVP 
Receiver Proxy. Section 3 defines useful terminology. Section 4 
then presents several fundamental RSVP proxy approaches, discussing 
how they achieve the necessary synchronization of RSVP reservations 
with application-level requirements. Appendix A includes more 
detailed use cases for the proxies in various real-life deployment 
environments. 


It is important to keep in mind that the strongly recommended RSVP 
deployment model remains end-to-end as assumed in [RFC2205] with RSVP 
support on the sender and the receiver. The end-to-end model allows 
the most effective synchronization between the reservation and 
application requirements. Also, when compared to the end-to-end RSVP 
model, the use of RSVP proxies involves additional operational burden 
and/or imposes some topological constraints. The additional 
operational burden comes in particular from additional configuration 
needed to activate the RSVP proxies and to help them identify for 
which senders/receivers a proxy behavior is required and for which 
senders/receivers it is not (so that an RSVP proxy does not perform 
establishment of reservations on behalf of devices that are capable 
of doing so themselves but would then be prevented -- without 
notification -- from doing so by the RSVP proxy). The additional 
topological constraints come in particular from the requirement to 
have one RSVP Receiver Proxy on the path from any sender to every 
non-RSVP-capable device (so that a non-RSVP-capable device is always 
taken care of by an RSVP proxy) and the objective to have only one 
such Receiver Proxy on the path from any sender to every non-RSVP- 
capable device (so that an RSVP Receiver Proxy does not short-circuit 
another RSVP Receiver Proxy closer to the non-RSVP-capable device, 
thereby reducing the span of the RSVP reservation and the associated 
benefits). In the case of the Path-Triggered Receiver Proxy 
approach, the operational burden and topological constraints can be 
Significantly alleviated using the mechanisms discussed in 

Section 4.1.1. 


It is also worth noting that RSVP operations on end-systems are 
considerably simpler than on a router, and consequently that RSVP 
implementations on end-systems are very lightweight (particularly 
considering modern end-systems’ capabilities, including mobile and 
portable devices). For example, end-system RSVP implementations are 
reported to only consume low tens of kilobytes of code space. Hence, 
this document should not be seen as an encouragement to depart from 
the end-to-end RSVP model. Its purpose is only to allow RSVP 
deployment in special environments where RSVP just cannot be used on 
Some senders and/or some receivers for reasons specific to the 
environment. 
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2. RSVP Proxy Behaviors 


This section discusses the two types of proxies: the RSVP Sender 
Proxy operating on behalf of data senders, and the RSVP Receiver 
Proxy operating for data receivers. The concepts presented in this 
document are not meant to deprecate the traditional [RFC2205] RSVP 
end-to-end model: end-to-end RSVP reservations are still expected to 
be used whenever possible. However, RSVP proxies are intended to 
facilitate RSVP deployment where end-to-end RSVP signaling is not 
possible. 


2.1. RSVP Receiver Proxy 


With conventional end-to-end RSVP operations, RSVP reservations are 
controlled by receivers of data. After a data sender has sent an 
RSVP Path message towards the intended recipient(s), each recipient 
that requires a reservation generates a Resv message. If, however, a 
data receiver is not running the RSVP protocol, the last-hop RSVP 
router will still send the Path message to the data receiver, which 
will silently drop this message as an IP packet with an unknown 
protocol number. 


In order for reservations to be made in such a scenario, one of the 
RSVP routers on the data path determines that the data receiver will 
not be participating in the resource reservation signaling and 
performs RSVP Receiver Proxy functionality on behalf of the data 
receiver. This is illustrated in Figure 1. Various mechanisms by 
which the RSVP proxy router can gain the required information are 
discussed later in the document. 


| ***x | KKK KKK | cese | |---- | 

| S  |--------- *p*---------- *p*--------- | RSVP | ---------- | R | 

|****| KKK KKK | Receiver | |---- | 
Proxy 


KKKKKKKKKK 


RSVP > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKD 


|****| RSVP-capable |----| non-RSVP-capable Ate 
| S | Sender | R | Receiver *r* regular RSVP 
|****| |---- | *** router 


***» unidirectional media flow 
==> segment of flow path protected by RSVP reservation 


Figure 1: RSVP Receiver Proxy 
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2.2. RSVP Sender Proxy 


With conventional end-to-end RSVP operations, if a data sender is not 
running the RSVP protocol, a resource reservation cannot be set up; a 
data receiver alone cannot reserve resources without Path messages 
first being received. Thus, even if the data receiver is running 
RSVP, it still needs some node on the data path to send a Path 
message towards the data receiver. 


In that case, an RSVP node on the data path determines that it should 
generate Path messages to allow the receiver to set up the resource 
reservation. This node is referred to as the RSVP Sender Proxy and 
is illustrated in Figure 2. This case presents additional challenges 
over the Receiver Proxy case, since the RSVP Sender Proxy must be 
able to generate all the information in the Path message (such as the 
SENDER TSPEC object) without the benefit of having previously 
received any RSVP message. An RSVP Receiver Proxy, by contrast, only 
needs to formulate an appropriate Resv message in response to an 
incoming Path message. Mechanisms to operate an RSVP Sender Proxy 
are discussed later in this document. 


tta KOK KK ck k KK KK kK XX 
| S | SaocSSSes RSVB-  [|m-55--4—— Kp*5--cec———-- A o iaaa R 
|----| | Sender | kK KKK |****| 
Proxy 
| sex | 
RSVP > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKD 


|----| non-RSVP-capable |****| RSVP-capable *** 
S Sender R Receiver *r* regular RSVP 
zum KKKK *kk router 


***» unidirectional media flow 
==> segment of flow path protected by RSVP reservation 
Figure 2: RSVP Sender Proxy 
3. Terminology 
o On-Path: located on the data path of the actual flow of 


application data (regardless of where it is located with respect 
to the application-level signaling path). 
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o Off-Path: not On-Path. 


o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per 
[RFC2205]. 


o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf 
of a receiver, the RSVP operations that would normally be 
performed by an RSVP-capable receiver if end-to-end RSVP signaling 
were used. Note that while RSVP is used upstream of the RSVP 
Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 
Proxy. 


o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of 
a sender, the RSVP operations that would normally be performed by 
an RSVP-capable sender if end-to-end RSVP signaling were used. 
Note that while RSVP is used downstream of the RSVP Sender Proxy, 
RSVP is not used upstream of the RSVP Sender Proxy. 


o Regular RSVP Router: an RSVP-capable router that is not behaving 
as an RSVP Receiver Proxy or as an RSVP Sender Proxy. 


Oo Application-level signaling: signaling between entities operating 
above the IP layer and that are aware of the QoS requirements for 
actual media flows.  SIP ([RFC3261]) and the Real Time Streaming 
Protocol (RTSP) ([RFC2326]) are examples of application-level 
Signaling protocols. The Session Description Protocol (SDP) 
([RFC4566]) is an example of a protocol that can be used by the 
application-level signaling protocol and from which some of the 
RSVP reservation parameters (addresses, ports, and bandwidth) 
might be derived.  RSVP is clearly not an application-level 
Signaling protocol. 


The roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular 
RSVP router are all relative to a given unidirectional flow. A given 
router may act as the RSVP Receiver Proxy for a flow, as the RSVP 
Sender Proxy for another flow, and as a regular RSVP router for yet 
another flow. 


Some application-level signaling protocols support negotiation of QoS 
reservations for a media stream. For example, with [RFC3312], 
resource reservation requirements are explicitly signaled during 
session establishment using SIP and SDP. Also, [RFC5432] defines a 
mechanism to negotiate which resource reservation mechanism is to be 
used for a particular media stream. Clearly, these reservation 
negotiation mechanisms can be invoked and operate effectively when 
both ends support RSVP (and obviously RSVP proxies are not used). 
When both ends do not support RSVP (and RSVP proxies are used at both 
ends), these mechanisms will simply not be invoked. In the case 
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4. 


4. 


where one end supports RSVP and the other does not (and is helped by 
an RSVP proxy), the application-level signaling entity supporting the 
non-RSVP-capable end might use the reservation negotiation mechanisms 
in such a way that the non-RSVP-capable end (helped by an RSVP proxy) 
appears to the remote end as an RSVP-capable device. This will 
ensure that the RSVP-capable end is not discouraged from using RSVP 
because the remote end is not RSVP-capable. In the case of SIP, the 
application-level entity may achieve this by taking advantage of the 
"segmented" status type of [RFC3312] and/or by taking advantage of a 
SIP [RFC3261] Back-to-Back User Agent (B2BUA). 


RSVP Proxy Approaches 
This section discusses fundamental RSVP proxy approaches. 
1. Path-Triggered Receiver Proxy 


In this approach, it is assumed that the sender is RSVP-capable and 
takes full care of the synchronization between application 
requirements and RSVP reservations. With this approach, the RSVP 
Receiver Proxy uses the RSVP Path messages generated by the sender as 
the cue for establishing the RSVP reservation on behalf of the 
receiver. The RSVP Receiver Proxy is effectively acting as a slave 
making reservations (on behalf of the receiver) under the sender’s 
control. This changes somewhat the usual RSVP reservation model 
where reservations are normally controlled by receivers. Such a 
change greatly facilitates operations in the scenario of interest 
here, which is where the receiver is not RSVP-capable. Indeed, it 
allows the RSVP Receiver Proxy to remain application-unaware by 
taking advantage of the application awareness and RSVP awareness of 
the sender. 


With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router 
may be configured to use receipt of a regular RSVP Path message as 
the trigger for RSVP Receiver Proxy behavior. 


On receipt of the RSVP Path message, the RSVP Receiver Proxy: 


1. establishes the RSVP Path state as per regular RSVP processing. 


2. identifies the downstream interface towards the receiver. 

3. sinks the Path message. 

4. behaves as if a Resv message (whose details are discussed below) 
was received on the downstream interface. This includes 


performing admission control on the downstream interface, 
establishing a Resv state (in case of successful admission 
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control), and forwarding the Resv message upstream, sending 
periodic refreshes of the Resv message and tearing down the 
reservation if the Path state is torn down. 


In order to build the Resv message, the RSVP Receiver Proxy can take 
into account information received in the Path message. For example, 
the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv 
message that mirrors the SENDER TSPEC object in the received Path 
message (as an RSVP-capable receiver would typically do). 


Operation of the Path-Triggered Receiver Proxy in the case of a 
successful reservation is illustrated in Figure 3. 


[xxx | KKK KK | cese | |----| 

| S  |--------- *p*---------- *p*--------- | RSVP | ---------- | R 

|****| KK KKK Receiver |---- | 
Proxy 


| ex | 


sezPath----2 -—--Pagth----»:.---Pathe---- 
&-c-cRéeSy---» Kem RE y= SeH «csResv---- 
RSVP > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKD 


|****| RSVP-capable |----| Non-RSVP-capable TN 
| S | Sender | R | Receiver *r* regular RSVP 
|****| |---- | *** router 


***» media flow 
==> segment of flow path protected by RSVP reservation 
Figure 3: Path-Triggered RSVP Receiver Proxy 


In case the reservation establishment is rejected (for example, 
because of an admission control failure on a regular RSVP router on 
the path between the RSVP-capable sender and the RSVP Receiver 
Proxy), a ResvErr message will be generated as per conventional RSVP 
operations and will travel downstream towards the RSVP Receiver 
Proxy. While this ensures that the RSVP Receiver Proxy is aware of 
the reservation failure, conventional RSVP procedures do not cater to 
the notification of the sender of the reservation failure. Operation 
of the Path-Triggered RSVP Receiver Proxy in the case of an admission 
control failure is illustrated in Figure 4. 
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[xx | KKK KKK | cese | |---- | 
Sn MTS a EpAcu—eeeeeee- Apr RSVP | SSR R 
| | | | 
|****| KKK KKK Receiver |---- | 
Proxy 


| ese x | 


scePathe-sxo2---Path----2x.---Path-e---» 
<== sResvssss> <==ResvsssS== 
---ResvErr---» --ResvErr---» 
RSVP > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKD 


| ****| RSVP-capable |----| Non-RSVP-capable Aw 
| S | Sender | R | Receiver *r* regular RSVP 
|****| |---- | *** router 


***» media flow 
==> segment of flow path protected by RSVP reservation 
Figure 4: Path-Triggered RSVP Receiver Proxy with Failure 


Since, as explained above, in this scenario involving the RSVP 
Receiver Proxy, synchronization between an application and an RSVP 
reservation is generally performed by the sender, notifying the 
sender of reservation failure is needed.  [RFC5946] specifies RSVP 
extensions allowing such sender notification in the case of 
reservation failure in the presence of a Path-Triggered RSVP Receiver 


Proxy. 
4.1.1. Mechanisms for Maximizing the Reservation Span 


The presence in the flow path of a Path-Triggered RSVP Receiver Proxy 
(for a given flow) that strictly behaves as described previously 
would cause the Path message to be terminated and a Resv message to 
be generated towards the sender. When the receiver is indeed not 
RSVP-capable and there is no other RSVP Receiver Proxy downstream on 
the flow path, this achieves the best achievable result of 
establishing an RSVP reservation as far downstream as the RSVP 


Receiver Proxy. 
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However, if the eventual receiver was in fact RSVP-capable, it would 
be prevented from participating in RSVP signaling, since it does not 
receive any Path message. As a result, the RSVP reservation would 
only span a subset of the path it could actually span. A similar 
sub-optimality would exist with multiple Receiver Proxies in the path 
of the flow: the first Receiver Proxy may prevent the Path message 
from reaching the second one and therefore prevent the reservation 
from extending down to the second Receiver Proxy. 


It is desirable that, in the presence of Path-Triggered RSVP Receiver 
Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers, 
the RSVP reservation spans as much of the flow path as possible. 

This can be achieved dynamically (avoiding tedious specific 
configuration), using the mechanisms described in Sections 4.1.1.1 
and 4.1.1.2. 


4.1.1.1. Dynamic Discovery of Downstream RSVP Functionality 


When generating a proxy Resv message upstream, a Receiver Proxy may 
be configured to perform dynamic discovery of downstream RSVP 
functionality. To that end, when generating the proxy Resv message 
upstream, the Receiver Proxy forwards the Path message downstream 
instead of terminating it. This allows an RSVP-capable receiver (or 
a downstream Receiver Proxy) to respond to the Path with an upstream 
Resv message. On receipt of a Resv message, the Receiver Proxy 
internally converts its state from a proxied reservation to a regular 
midpoint RSVP behavior. From then on, everything proceeds as if the 
RSVP router had behaved as a regular RSVP router at reservation 
establishment (as opposed to having behaved as an RSVP Receiver Proxy 
for that flow). 


The RSVP Receiver Proxy behavior for dynamic discovery of downstream 
RSVP functionality is illustrated in Figure 5 and is also discussed 
in Section 4.1 of [RFC5946]. 
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[x | KKK FIR I I | |---- | 
S |--------- *p*--------- | RSVP |---| R1 | 
prex | Ar Receiver |----| 
Proxy 
| | [xxxx | 
| |------------ | Re | 
[A ka xxx oe | |****| 
---Path---»  --Path---» 
(R1) (R1) N------- Path--» 
/ (R1) 
«--ReSV---, €--cResv--- 
RSVP > 
FR IR IO I I I I IR IR I I I IIS 
---Path---»  --Path---» 
(R2) (R2) N------------- Path----» 
/ (R2) 
«-cZcReSV-o--- oE—ScReéSV--- 
«----Resv--- 
RSVP > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKD 


|****| RSVP-capable |----| non-RSVP-capable  |****| RSVP-capable 
| S | Sender | R | Receiver | R | Receiver 
|****| |---- | |****| 

**** 


*r* regular RSVP 
*** router 


(R1) = Path message contains a Session object whose destination is R1 
***» media flow 
==> segment of flow path protected by RSVP reservation 

Figure 5: Dynamic Discovery of Downstream RSVP Functionality 
This dynamic discovery mechanism has the benefit that new (or 


upgraded) RSVP endpoints will automatically and seamlessly be able to 
take advantage of end-to-end reservations, without impacting the 


Le Faucheur, et al. Informational [Page 13] 


RFC 5945 RSVP Proxy Approaches October 2010 


ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable 
endpoints. This mechanism also achieves the goal of automatically 
discovering the longest possible RSVP-supporting segment in a network 
with multiple Receiver Proxies along the path. This mechanism 
dynamically adjusts to any topology and routing change. Also, this 
mechanism dynamically handles the situation in which a receiver was 
RSVP-capable and for some reason (e.g., software downgrade) no longer 
is. Finally, this approach requires no new RSVP protocol extensions 
and no configuration changes to the Receiver Proxy as new RSVP- 
capable endpoints come and go. 


The only identified drawbacks to this approach are: 


o If admission control fails on the segment between the Receiver 
Proxy and the RSVP-capable receiver, the receiver will get a 
ResvErr and can take application-level signaling steps to 
terminate the call. However, the Receiver Proxy has already sent 
a Resv upstream for this flow, so the sender will see a "false" 
reservation that is not truly end-to-end. The actual admission 
control status will resolve itself in a short while, but the 
sender will need to roll back any permanent action (such as 
billing) that may have been taken on receipt of the phantom Resv. 
Note that if the second receiver is also a Receiver Proxy that is 
not participating in application signaling, it will convert the 
received ResvErr into a PathErr that will be received by the 
sender. 


o If there is no RSVP-capable receiver (or other Receiver Proxy) 
downstream of the Receiver Proxy, then the Path messages sent by 
the Receiver Proxy every RSVP refresh interval (e.g., 30 seconds 
by default) will never be responded to. However, these messages 
consume a small amount of bandwidth, and in addition would install 
some RSVP state on RSVP-capable midpoint nodes downstream of the 
first Receiver Proxy. This is seen as a very minor sub- 
optimality. We also observe that such resources would be consumed 
anyways if the receiver was RSVP-capable. Still, if deemed 
necessary, to mitigate this, the Receiver Proxy can tear down any 
unanswered downstream Path state and stop sending Path messages 
for the flow (or only send them at much lower frequency) as 
further discussed in [RFC5946]. 


4.1.1.2. Selective Receiver Proxy and Sender Control of Receiver Proxy 


An RSVP Receiver Proxy can be selective about the sessions that it 
terminates, based on local policy decision. For example, an edge 
router functioning as a Receiver Proxy may behave as a proxy only for 
Path messages that are actually going to exit the domain in question, 
and not for Path messages that are transiting through it but stay 
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within the domain. As another example, the Receiver Proxy may be 
configurable to only proxy for flows addressed to a given destination 
address or destination address ranges (for which end devices are 
known to not be RSVP-capable). 


The decision to proxy a Resv for a Path may also be based on 
information signaled from the sender in the Path message. For 
example, the sender may identify the type of application or flow in 
the Application Identity policy element ([RFC2872]) in the Path, and 
the Receiver Proxy may be configured to proxy for only certain types 
of flows. Or, if the sender knows (for example, through application 
signaling) that the receiver is RSVP-capable, the sender can include 
an indication in a policy element to any Receiver Proxy that it ought 
not to terminate the Path (or conversely, if the receiver is known 
not to support RSVP, the sender could include an indication to 
Receiver Proxies that they ought to generate a proxy Resv message). 
The Receiver Proxy Control policy element specified in Section 4.2 of 
[RFC5946] can be used for that purpose. 


4.2.  Path-Triggered Sender Proxy for Reverse Direction 


In this approach, it is assumed that one endpoint is RSVP-capable and 
takes full care of the synchronization between application 
requirements and RSVP reservations. This endpoint is the sender for 
one flow direction (which we refer to as the "forward" direction) and 
is the receiver for the flow in the opposite direction (which we 
refer to as the "reverse" direction). 


With the Path-Triggered Sender Proxy for Reverse Direction approach, 
the RSVP proxy uses the RSVP signaling generated by the receiver (for 
the reverse direction) as the cue for initiating RSVP signaling for 
the reservation in the reverse direction. More precisely, the RSVP 
proxy can take the creation (or maintenance or teardown) of a Path 
state by the receiver as the cue to create (or maintain or tear down, 
respectively) a Path state towards the receiver. Thus, the RSVP 
proxy is effectively acting as a Sender Proxy for the reverse 
direction under the control of the receiver (for the reverse 
direction). Note that this assumes a degree of symmetry, for 
example, in terms of bandwidth for the two directions of the flow (as 
is currently typical for IP telephony). 


The signaling flow for the Path-Triggered Sender Proxy for Reverse 
Direction is illustrated in Figure 6. 


Path messages generated by the receiver need to transit via the RSVP 
Sender Proxy that is on the path from the sender to the receiver. In 
some topologies, this will always be the case: for example, where the 
sender is on a stub network hanging off the RSVP Sender Proxy or 
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where there is no asymmetric routing (such that if an RSVP Sender 
Proxy is on the path from receiver to sender, then it is also on the 
path from sender to receiver). In some topologies (such as those 
involving asymmetric routing), this may not always happen naturally. 
Measures to ensure this does happen in these topologies are outside 
the scope of this document. 


[x | KK KKK | cese | |---- | 

R  |--------- *p*---------- *p*--------- RSVP — [---------- | S | 

KX XX kXX *k Sender NP 
| Proxy | 


| x xxx xxx | 


--sPath---» 2---Püth----5. ---Path----» 
«--Path---» «---Path----- &-zPath---- 
SESRESVH EE? uu--RéSV----» c—3BesWwo-ccx 
« RSVP 


UKCkCKk kk Ck Kk KK kk Sk Ck CK Ck CK CC CK CK C KC CK CK Sk kk kk ck kk ko kc kck KKK KK 


| ****| RSVP-capable |----| Non-RSVP-capable xxx 
| R | Receiver for | S | Sender for *r* regular RSVP 
|****| reverse direction |----| reverse direction *** router 


***» media flow 


==> segment of flow path protected by RSVP reservation 
in reverse direction 


Figure 6: Path-Triggered Sender Proxy for Reverse Direction 


Of course, the RSVP proxy may simultaneously (and typically will) 
also act as the Path-Triggered Receiver Proxy for the forward 


direction, as defined in Section 4.1. Such an approach is most 
useful in situations involving RSVP reservations in both directions 
for symmetric flows. This is illustrated in Figure 7. 
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|---------- | 
---Path---» ----Path----» ---Path----» 
«--Resv---» «---Resv----- «--Resv---- 
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|| RSVP-capable |----| Non-RSVP-capable KER 
|S/R | Sender and |S/R | Sender and *r* regular RSVP 
|****| Receiver |----| Receiver *** router 


***» media flow 


==> segment of flow path protected by RSVP reservation 
in forward and in reverse direction 


Figure 7: Path Triggered Receiver and Sender Proxy 


With the Path-Triggered Sender Proxy for Reverse Direction approach, 
the RSVP router may be configurable to use receipt of a regular RSVP 
Path message as the trigger for Sender Proxy for Reverse Direction 
behavior. 


On receipt of the RSVP Path message for the forward direction, the 
RSVP Sender Receiver Proxy: 


1. sinks the Path message. 
2. behaves as if a Path message for the reverse direction (whose 
details are discussed below) had been received by the Sender 


Proxy. This includes establishing the corresponding Path state, 
forwarding the Path message downstream, sending periodic 
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refreshes of the Path message, and tearing down the Path in the 
reverse direction when the Path state in the forward direction is 
torn down. 


In order to build the Path message for the reverse direction, the 
RSVP Sender Proxy can take into account information in the received 
Path message for the forward direction. For example, the RSVP Sender 
Proxy may mirror the SENDER TSPEC object in the received Path 
message. 


We observe that this approach does not require any extensions to the 
existing RSVP protocol. 


In the case where reservations are required in both directions (as 
shown in Figure 7), the RSVP-capable device simply needs to behave as 
a regular RSVP sender and RSVP receiver. It need not be aware that 
an RSVP proxy happens to be used, and the Path message it sent for 
the forward reservation also acts as the trigger for establishment of 
the reverse reservation. However, in the case where a reservation is 
only required in the reverse direction (as shown in Figure 6), the 
RSVP-capable device has to generate Path messages in order to trigger 
the reverse-direction reservation even if no reservation is required 
in the forward direction. Although this is not in violation of 
[RFC2205], it may not be the default behavior of an RSVP-capable 
device and therefore may need a behavioral change specifically to 
facilitate operation of the Path-Triggered Sender Proxy for Reverse 
Direction. 


4.3.  Inspection-Triggered Proxy 


In this approach, it is assumed that the RSVP proxy is on the data 
path of "packets of interest", that it can inspect such packets on 
the fly as they transit through it, and that it can infer information 
from these packets of interest to determine what RSVP reservations 
need to be established, as well as when and with what characteristics 
(possibly also using some configured information). 


One example of "packets of interest" could be application-level 
signaling. An RSVP proxy capable of inspecting SIP signaling for a 
multimedia session or RTSP signaling for video streaming can obtain 
from such signaling information about when a multimedia session is up 
or when a video is going to be streamed. It can also identify the 
addresses and ports of senders and receivers and can determine the 
bandwidth of the corresponding flows. It can also determine when the 
reservation is no longer needed and tear it down. Thus, such an RSVP 
proxy can determine all necessary information to synchronize RSVP 
reservations to application requirements. This is illustrated in 
Figure 8. 
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—— | 
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| S |-------- | RSVP = |------ *p*-------- | RSVP | |---------- | R | 
|---- | | Proxy | ASS | Proxy | |---- | 
[xx | | xx | 
RSVP > 
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|----| Non-RSVP-capable |----| Non-RSVP-capable wae 
| S | Sender | R | Receiver *r* regular RSVP 


*** router 
</\> application-level signaling 
***» media flow 
==> segment of flow path protected by RSVP reservation 
Figure 8: Inspection-Triggered RSVP Proxy 


Another example of "packets of interest" could be transport control 
messages (e.g., the Real-time Transport Control Protocol (RTCP) 
[RFC3550]) traveling alongside the application flow itself (i.e., 
media packets). An RSVP proxy capable of detecting the transit of 
packets from a particular flow can attempt to establish a reservation 
corresponding to that flow. Characteristics of the reservation may 
be derived by various methods such as from configuration, flow 
measurement, or a combination of those. However, these methods 
usually come with their respective operational drawbacks: 
configuration involves an operational cost and may hinder 
introduction of new applications, and measurement is reactive so that 
accurate reservation may lag actual traffic. 


In the case of reservation failure, the Inspection-Triggered RSVP 


Proxy does not have a direct mechanism for notifying the application 
(since it is not participating itself actively in application 
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signaling) so that the application is not in a position to take 
appropriate action (for example, terminate the corresponding 
session). To mitigate this problem, the Inspection-Triggered RSVP 
Proxy may differently mark the Differentiated Services codepoint 
(DSCP) ([RFC2474]) of flows for which an RSVP reservation has been 
successfully proxied from the flows for which a reservation is not in 
place. In some situations, the Inspection-Triggered Proxy might be 
able to modify the "packets of interest" (e.g., application signaling 
messages) to convey some hint to applications that the corresponding 
flows cannot be guaranteed by RSVP reservations. 


With the Inspection-Triggered Proxy approach, the RSVP proxy is 
effectively required to attempt to build application awareness by 
traffic inspection and then is somewhat limited in the actions it can 
take in case of reservation failure. Depending on the "packets of 
interest" used by the RSVP proxy to trigger the reservation, there is 
a risk that the RSVP proxy will end up establishing a reservation for 
a media flow that actually never starts. However, this can be 
mitigated by the timing out and tearing down of an unnecessary 
reservation by the RSVP proxy when no corresponding media flow is 
observed. This flow observation and timeout approach can also be 
used to tear down reservations that were rightfully established for a 
flow but are no longer needed because the flow stopped. 


The Inspection-Triggered approach is also subject to the general 
limitations associated with data inspection. This includes being 
impeded by encryption or tunneling, or being dependent on some 
topology constraints such as relying on the fact that both the 
packets of interest and the corresponding flow packets always transit 
through the same RSVP proxy. 


Nonetheless, this may be a useful approach in specific environments. 
Note also that this approach does not require any change to the RSVP 
protocol. 


With the Inspection-Triggered RSVP Proxy approach, the RSVP router 
may be configurable to use and interpret some specific packets of 
interest as the trigger for RSVP Receiver Proxy behavior. 


When operating off signaling traffic, the Inspection-Triggered RSVP 
Proxy may be able to detect from the signaling that the endpoint is 
capable of establishing an RSVP reservation (e.g., in the case of 
SIP, via the inspection of the [RFC3312]/[RFC4032] precondition), in 
which case it would not behave as a proxy for that endpoint. Also, 
the Inspection-Triggered RSVP Proxy may inspect RSVP signaling, and 
if it sees RSVP signaling for the flow of interest, it can disable 
its Sender Proxy behavior for that flow (or that sender). 

Optionally, through RSVP signaling inspection, the Sender Proxy might 
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also gradually "learn" (possibly with some timeout) which sender is 
RSVP-capable and which is not. These mechanisms can facilitate 
gradual and dynamic migration from the proxy model towards the end- 
to-end RSVP model as more and more endpoints become RSVP-capable. 


4.4. STUN-Triggered Proxy 


In this approach, the RSVP proxy takes advantage of the application 
awareness provided by the Session Traversal Utilities for NAT (STUN) 
([REC5389]) signaling to synchronize RSVP reservations with 
application requirements. The STUN signaling is sent from endpoint 
to endpoint. This is illustrated in Figure 9. In this approach, a 
STUN message triggers the RSVP proxy. 


a KKKKKKKK *kk KKKKKKKK Imm 
S |-------- RSVP | |------ *p*-------- RSVP | |---------- R 
|---- | | Proxy | AA | Proxy | |---- | 
| exse | xx | 
BINDS VIN ANSA ISAS OLS OLY IS SNS AEI ES VI IN IS GRIN, IN LAN ES IS AN ALANIS ISIN OS NS ANA AAE ESAN LEIN AN ANEAN EE ANN HIN AN ANC ORSON: S 
RSVP > 
CKCKCk ck kCkckckckckckckckckckck ck ck k ck ck k ck ck ck ck ck k ck ck k ck ck ck ck ck kck ck ck k ck ck ck ck ck ck ck ck ck k k k kk 
----| Non-RSVP-capable ----| Non-RSVP-capable BORN 
S Sender R Receiver *r* regular RSVP 


|----| *** router 


^^^» STUN message flow (over same UDP ports as media flow) 
==> segment of flow path protected by RSVP reservation 


***» RTP media flow 
Figure 9: STUN-Triggered Proxy 


For unicast flows, [RFC5245] is a widely adopted approach for Network 
Address Translator (NAT) traversal. For our purposes of triggering 
RSVP proxy behavior, we rely on the Interactive Connectivity 
Establishment (ICE) protocol's connectivity check, which is based on 
the exchange of STUN Binding Request messages between hosts to verify 
connectivity (see Section 2.2 of [RFC5245]). The STUN message could 
also include (yet to be specified) STUN attributes to indicate 
information such as the bandwidth and application requesting the 
flow, which would allow the RSVP proxy agent to create an 
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appropriately sized reservation for each flow. Including such new 
STUN attributes in the ICE connectivity check messages would 
facilitate operation of the RSVP proxy. To ensure RSVP reservations 
are only established when needed, the RSVP proxy needs to 
distinguish, among all the STUN messages, the ones that reflect (with 
high likelihood) an actual upcoming media flow. This can be achieved 
by identifying the STUN messages associated with an ICE connectivity 
check. In turn, this can be achieved through (some combination of) 
the following checks: 


o if, as discussed above, new STUN attributes (e.g., conveying the 
flow bandwidth) are indeed defined in the future in view of 
facilitating STUN-Triggered reservations, then the presence of 
these attributes would reveal that the STUN message is part of an 
ICE connectivity check. 


o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, or 
ICE-CONTROLLING attributes reveals that the STUN message is part 
of an ICE connectivity check. 


o the RSVP proxy may wait for a STUN message containing the USE- 
CANDIDATE attribute indicating the selected ICE "path" to trigger 
reservation only for the selected "path". This allows the RSVP 
proxy to only trigger a reservation for the "path" actually 
selected and therefore for the media flow that will actually be 
established (for example, when ICE is being used for IPv4/v6 path 
selection). 


o the RSVP proxy configuration could contain some information 
facilitating determination of when to perform RSVP proxy 
reservation and when not to. For example, the RSVP proxy 
configuration could contain the IP addresses of the STUN servers 
such that STUN messages to/from those addresses are known to not 
be part of an ICE connectivity check. As another example, the 
RSVP proxy configuration could contain information identifying the 
set of Differentiated Services codepoint (DSCP) values that the 
media flows requiring reservation use, so that STUN messages not 
using one of these DSCP values are known to not be part of an ICE 
connectivity check. 


Despite these checks, there is always a potential risk that the RSVP 
proxy will end up establishing a reservation for a media flow that 
actually never starts. However, this is limited to situations in 
which the end-systems are interested enough in establishing 
connectivity for a flow but never transmit. Also, this can be 
mitigated by timing out and tear down of an unnecessary reservation 
by the RSVP proxy when no corresponding media flow is observed. 
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The RSVP proxy agent can inform endpoints of an RSVP reservation 
failure implicitly by dropping the ICE connectivity check message or 
explicitly by sending ICMP messages back to the endpoint. This 
allows reasonably effective synchronization between RSVP reservations 
handled by the RSVP proxies and the application running on non-RSVP- 
capable endpoints. It also has the benefits of operating through 
NATs. 


For multicast flows (or certain kinds of unicast flows that don't or 
can't use ICE), a STUN Indication message [RFC5389] could be used to 
carry the (yet to be defined) STUN attributes mentioned earlier to 
indicate the flow bandwidth, thereby providing a benefit similar to 
the ICE connectivity check.  STUN Indication messages are not 
acknowledged by the receiver and have the same scalability as the 
underlying multicast flow. 


The corresponding extensions to ICE and STUN for such a STUN- 
Triggered RSVP Proxy approach are beyond the scope of this document. 
They may be defined in the future in a separate document. As the 
STUN-Triggered RSVP Proxy approach uses STUN in a way (i.e., to 
trigger reservations) that is beyond its initial intended purpose, 
the potential security implications need to be considered by the 
operator. 


ICE connectivity checks are not always used for all flows. When the 
STUN-Triggered RSVP Proxy approach is used, it can establish RSVP 
reservations for flows for which ICE connectivity is performed. 
However, the STUN-Triggered RSVP Proxy will not establish a 
reservation for flows for which an ICE connectivity check is not 
performed. Those flows either will not benefit from an RSVP 
reservation or can benefit from an RSVP reservation established 


through other means (end-to-end RSVP, other forms of RSVP proxy). 


The STUN-Triggered approach relies on interception and inspection of 
STUN messages. Thus, this approach may be impeded by encryption or 
tunneling. 


4.5. Application Entity-Controlled Proxy 


In this approach, it is assumed that an entity involved in the 
application-level signaling controls an RSVP proxy that is located in 
the data path of the application flows (i.e., "on-path"). With this 
approach, the RSVP proxy does not itself attempt to determine the 
application reservation requirements. Instead, the RSVP proxy is 
instructed by the entity participating in application-level signaling 
to establish, maintain, and tear down reservations as needed by the 
application flows. In other words, with this approach, the solution 
for synchronizing RSVP signaling with application-level requirements 
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is to rely on an application-level signaling entity that controls an 
RSVP proxy function that sits in the flow data path. This approach 
allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or 
both. 


Operation of the Application Entity-Controlled Proxy is illustrated 
in Figure 10. 
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/ // \\ \ 
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/ // \\ \ 

/ // \\ \ 
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|---- | | RSVP | wae | RSVP | |---- | 
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**** 


*r* regular RSVP 
*** router 


|----| Non-RSVP-capable 
| R | Receiver 


|----| Non-RSVP-capable 
| S | Sender 


***» media flow 


==> segment of flow path protected by RSVP reservation 
/\ Application signaling (e.g., SIP) 
// RSVP proxy control interface 


Figure 10: Application Entity-Controlled Proxy 


As an example, the Application Entity-Controlled Proxy may be used in 
the context of SIP servers ([RFC3261]) or Session Border Controllers 
(SBCs) (see [RFC5853] for a description of SBCs) to establish RSVP 
reservations for multimedia sessions. In that case, the application 
entity may be the signaling component of the SBC. 
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This RSVP proxy approach does not require any extension to the RSVP 
protocol. However, it relies on an RSVP proxy control interface 
allowing control of the RSVP proxy by an application signaling 
entity. This RSVP proxy control interface is beyond the scope of 
this document. Candidate protocols for realizing such an interface 
include the IETF Network Configuration (NETCONF) Protocol ([RFC4741], 
[RFC5277]), the Web Services protocol ([W3C]), the QoS Policy 
Information Model (QPIM) ([RFC3644]), and Diameter ([RFC3588]). This 
interface can rely on soft states or hard states. Clearly, when hard 
states are used, those need to be converted appropriately by the RSVP 
proxy entities into the corresponding RSVP soft states. As an 
example, [RFC5866] is intended to allow control of RSVP proxy via 
Diameter. 


In general, the application entity is not expected to maintain 
awareness of which RSVP Receiver Proxy is on the path to which 
destination. However, in the particular cases where it does so 
reliably, we observe that the application entity could control the 
RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP 
reservations are used between those, instead of one reservation per 
flow. For example, these aggregate reservations could be of the 
RSVP-AGGREGATE type, as specified in [RFC3175], or of the GENERIC- 
AGGREGATE type, as specified in [RFC4860]. Such aggregate 
reservations could be used so that a single reservation can be used 
for multiple (possibly all) application flows transiting via the same 
RSVP Sender Proxy and the same RSVP Receiver Proxy. 


For situations in which only the RSVP Sender Proxy has to be 
controlled by this interface, the interface may be realized through 
the simple use of RSVP itself, over a Generic Routing Encapsulation 
(GRE) tunnel from the application entity to the RSVP Sender Proxy. 
This particular case is further discussed in Section 4.5.1. Another 
particular case of interest is where the application signaling entity 
resides on the same device as the RSVP proxy. In that case, this 
interface may be trivially realized as an internal API. An example 
environment based on this particular case is illustrated in 

Section 4.5.2. 


The application entity controlling the RSVP proxy (e.g., a SIP Call 
Agent) would often be aware of a number of endpoint capabilities, and 
it has to be aware of which endpoint can be best "served" by which 
RSVP proxy anyways. So it is reasonable to assume that such an 
application is aware of whether a given endpoint is RSVP-capable or 
not. The application may also consider the QoS preconditions and QoS 
mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and 
[RFC5432]. The information about endpoint RSVP capability can then 
be used by the application to decide whether to trigger proxy 
behavior or not for a given endpoint. This can facilitate gradual 
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and dynamic migration from the proxy model towards the end-to-end 
RSVP model as more and more endpoints become RSVP-capable. 


In some environments, the application entities (e.g., SIP back-to- 
back user agents) that need to control the RSVP proxies would already 
be deployed independently of the use, or not, of the 

Application Entity-Controlled Proxy approach. In this case, the 
activation of the RSVP proxy approach should not introduce 
significant disruption in the application signaling path. In some 
environments, additional application entities may need to be deployed 
to control the RSVP proxies. In this case, the network operator 
needs to consider the associated risks of disruption to the 
application signaling path. 


4.5.1. Application Entity-Controlled Sender Proxy Using "RSVP over GRE" 


This approach is simply a particular case of the more general 
Application Entity-Controlled Proxy, but where only RSVP Sender 
Proxies need to be controlled by the application, and where RSVP is 
effectively used as the control protocol between the application- 
signaling entity and the RSVP Sender Proxy. 


In this approach, the RSVP messages (e.g., RSVP Path message) are 
effectively generated by the application entity and logically 
"tunneled" to the RSVP Sender Proxy via GRE tunneling. This is to 
ensure that the RSVP messages follow the exact same path as the flow 
they protect (as required by RSVP operations) on the segment of the 
end-to-end path that is to be subject to RSVP reservations. 


Figure 11 illustrates such an environment. 
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***» media flow 

==> segment of flow path protected by RSVP reservation 
/\ Application-level signaling 

/=/  GRE-tunneled RSVP (Path messages) 


Figure 11: Application Entity-Controlled Sender Proxy via 
"RSVP over GRE" 


With the Application Entity-Controlled Sender Proxy using "RSVP Over 
GRE", the application entity: 


O generates a Path message on behalf of the sender, corresponding to 
the reservation needed by the application, and maintains the 
corresponding Path state. The Path message built by the 
application entity is exactly the same as would be built by the 
actual sender (if it was RSVP-capable), with one single exception, 
which is that the application entity puts its own IP address as 
the RSVP previous hop. In particular, it is recommended that the 
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Source address of the Path message built by the application entity 
be set to the IP address of the sender (not of the application 
entity). This helps ensure that, in the presence of non-RSVP 
routers and of load-balancing in the network where the load- 
balancing algorithm takes into account the source IP address, the 
Path message generated by the application entity follows the exact 
same path as the actual stream sourced by the sender. 


o encapsulates the Path message into a GRE tunnel whose destination 
address is the RSVP Sender Proxy, i.e., an RSVP router sitting on 
the data path for the flow (and upstream of the segment that 
requires QoS guarantees via RSVP reservation). 


O processes the corresponding received RSVP messages (including Resv 
messages) as per regular RSVP. 


o synchronizes the RSVP reservation state with application-level 
requirements and signaling. 


Note that since the application entity encodes its own IP address as 
the previous RSVP hop inside the [RFC2205] RSVP HOP object of the 
Path message, the RSVP router terminating the GRE tunnel naturally 
addresses all the RSVP messages traveling upstream hop-by-hop (such 
as Resv messages) to the application entity (without having to 
encapsulate those in a reverse-direction GRE tunnel towards the 
application entity). 


4.5.2. Application Entity-Controlled Proxy via Co-Location 


This approach is simply a particular case of the more general 
Application Entity-Controlled Proxy, but where the application entity 
is co-located with the RSVP proxy. As an example, Session Border 
Controllers (SBCs) with on-board SIP agents could implement RSVP 
proxy functions and make use of such an approach to achieve session 
admission control over the SBC-to-SBC segment using RSVP signaling. 


Figure 12 illustrates operations of the Application Entity-Controlled 
RSVP Proxy via co-location. 
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|---- | | Sender | x | Receiver| |----| 

| Proxy | | Proxy | 
| eese | | esee | 
RSVP > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKED 


oa 


Non-RSVP-capable 
Sender 


E 


Non-RSVP-capable 
Receiver 


kkk 


*r* regular RSVP 
*** router 


***» media flow 


==> segment of flow path protected by RSVP reservation 


/\ 


Application-level signaling 
Figure 12: Application Entity-Controlled Proxy via Co-Location 


This RSVP proxy approach does not require any protocol extensions. 
We also observe that when multiple sessions are to be established on 
paths sharing the same RSVP Sender Proxy and the same RSVP Receiver 
Proxy, the RSVP proxies have the option to establish aggregate RSVP 
reservations (as defined in ([RFC3175] or [RFC4860]) for a group of 
sessions, instead of establishing one RSVP reservation per session. 


.6. Policy Server-Controlled Proxy 


it is assumed that a policy server, which is 
controls an RSVP proxy 


In this approach, 
located in the control plane of the network, 


that is located in the data path of the application flows (i.e., "on- 
path"). In turn, the policy server is triggered by an entity 
involved in the application-level signaling. With this approach, the 


RSVP proxy does not itself attempt to determine the application 
reservation requirements, but instead is instructed by the policy 
server to establish, maintain, and tear down reservations as needed 
by the application flows. Moreover, the entity participating in 
application-level signaling does not attempt to understand the 
Specific reservation mechanism (i.e., RSVP) or the topology of the 
network layer, but instead it simply asks the policy server to 
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perform (or tear down) a reservation. In other words, with this 
approach, the solution for synchronizing RSVP signaling with 
application-level requirements is to rely on an application-level 
entity that controls a policy server that, in turn, controls an RSVP 
proxy function that sits in the flow data path. This approach allows 
control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or both. 


Operation of the Policy Server-Controlled proxy is illustrated in 
Figure 13. 
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/ | ---------- | \ 
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/ | Server | \ 
foo ee \ 
/ // \\ \ 
/ // \\ \ 

/ // \\ \ 
|----| | cese | KKK | csse | |---- | 
| S  |----------- |------ *p*-----| | [---------- | R | 
|---- | | RSVP xxx | RSVP |---- | 

Sender Receiver 
| Proxy | | Proxy 
[xx | [eese | 

RSVP > 
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|----| Non-RSVP-capable |----| Non-RSVP-capable xxx 
| S | Sender | R | Receiver *r* regular RSVP 
|----| EXN router 


***» media flow 

==> segment of flow path protected by RSVP reservation 

/\ Application signaling (e.g., SIP) 

// RSVP proxy control interface 

I Interface between application entity and policy server 

Figure 13: Policy Server-Controlled Proxy 

This RSVP proxy approach does not require any extension to the RSVP 
protocol. However, as with the Application Entity-Controlled Proxy 
approach presented in Figure 10, this approach relies on an RSVP 
proxy control interface allowing control of the RSVP proxy (by the 
policy server in this case). This RSVP proxy control interface is 


beyond the scope of this document. Considerations about candidate 
protocols for realizing such an interface can be found in 
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Section 4.5. Again, for situations in which only the RSVP Sender 
Proxy has to be controlled by this interface, the interface may be 
realized through the simple use of RSVP itself, over a GRE tunnel 
from the policy server to the RSVP Sender Proxy. This is similar to 
what is presented in Section 4.5.1, except that the "RSVP over GRE" 
interface is used in this case by the policy server (instead of the 
application entity). 


The interface between the application entity and the policy server is 
beyond the scope of this document. 


4.7. RSVP-Signaling-Triggered Proxy 


An RSVP proxy can also be triggered and controlled through extended 
RSVP signaling from the remote end that is RSVP-capable (and supports 
these RSVP extensions for proxy control). For example, an RSVP- 
capable sender could send a new or extended RSVP message explicitly 
requesting an RSVP proxy on the path towards the receiver to behave 
as an RSVP Receiver Proxy and also to trigger a reverse-direction 
reservation, thus also behaving as an RSVP Sender Proxy. The new or 
extended RSVP message sent by the sender could also include 
attributes (e.g., bandwidth) for the reservations to be signaled by 
the RSVP proxy. 


The challenges in these explicit signaling schemes include the 
following: 


o How can the nodes determine when a reservation request ought to be 
proxied and when it should not, and accordingly invoke appropriate 
signaling procedures? 


o How does the node sending the messages explicitly triggering the 
proxy know where the proxy is located, e.g., determine an IP 
address of the proxy that should reply to the signaling? 


o How is all the information needed by a Sender Proxy to generate a 
Path message actually communicated to the proxy? 


An example of such a mechanism is presented in [QOS-MOBILE]. This 
Scheme is primarily targeted to local access network reservations 
whereby an end host can request resource reservations for both 
incoming and outgoing flows only over the access network. This may 
be useful in environments where the access network is typically the 
bottleneck while the core is comparatively over-provisioned, as may 
be the case with a number of radio access technologies. In this 
proposal, messages targeted to the proxy are flagged with one bit in 
all RSVP messages. Similarly, all RSVP messages sent back by the 
proxy are also flagged. The use of such a flag allows 
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differentiating between proxied and end-to-end reservations. For 
triggering an RSVP Receiver Proxy, the sender of the data sends a 
Path message that is marked with the mentioned flag. The Receiver 
Proxy is located on the signaling and data path, eventually gets the 
Path message, and replies back with a Resv message. A node triggers 
an RSVP Sender Proxy with a newly defined Path Request message, which 
instructs the proxy to send Path messages towards the triggering 
node. The node then replies back with a Resv. More details can be 
found in [QOS-MOBILE]. 


Such an RSVP-Signaling-Triggered Proxy approach would require RSVP 
signaling extensions (that are outside the scope of this document). 
However, it could provide more flexibility in the control of the 
proxy behavior (e.g., control of reverse reservation parameters) than 
would the Path-Triggered approaches defined in Section 4.1 and 
Section 4.2. 


Through potential corresponding protocol extensions, an RSVP- 
Signaling-Triggered Proxy approach could facilitate operation (e.g., 
reduce or avoid the need for associated configuration) in hybrid 
environments involving both reservations established end-to-end and 
reservations established via RSVP proxies. For example, [QOS-MOBILE] 
proposed a mechanism allowing an end-system to control whether a 
reservation can be handled by an RSVP proxy on the path, or is to be 
established end-to-end. 


4.8. Reachability Considerations 


There may be situations in which the RSVP Receiver Proxy is reachable 
by the sender, while the receiver itself is not. In such situations, 
it is possible that the RSVP Receiver Proxy is not always aware that 
the receiver is unreachable, and consequently may accept to establish 
an RSVP reservation on behalf of that receiver. This would result in 
unnecessary reservation establishment and unnecessary network 
resource consumption. 


This is not considered a significant practical concern for a number 
of reasons. First, in many cases, if the receiver is not reachable 
from the sender, it will not be reachable for application signaling 
either, and so application-level session establishment will not be 
possible in the first place. Secondly, where the receiver is 
unreachable from the sender but is reachable for application-level 
signaling (say, because session establishment is performed through an 
off-path SIP agent that uses a different logical topology to 
communicate with the receiver), then the sender may detect that the 
receiver is unreachable before attempting reservation establishment. 
This may be achieved through mechanisms such as ICE's connectivity 
check ([RFC5245]). Finally, even if the sender does not detect that 
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the receiver is unreachable before triggering the RSVP reservation 
establishment, it is very likely that the application will quickly 
realize this lack of connectivity (e.g., the human accepting the 
phone call on the receiver side will not hear the human's voice on 
the sender side) and therefore tear down the session (e.g., hang up 
the phone), which in turn will trigger RSVP reservation release. 


Nonetheless, it is recommended that network administrators consider 
the above in light of their particular environment when deploying 
RSVP proxies. 


The mirror considerations apply for situations involving an RSVP 
Sender Proxy and where the sender cannot reach the destination while 
the RSVP Sender Proxy can. 


5. Security Considerations 


In the environments of concern for this document, RSVP messages are 
used to control resource reservations on a segment of the end-to-end 
path of flows. The general security considerations associated with 
[RFC2205] apply. To ensure the integrity of the associated 
reservation and admission control mechanisms, the RSVP cryptographic 
authentication mechanisms defined in [RFC2747] and [RFC3097] can be 
used. Those protect RSVP messages integrity hop-by-hop and provide 
node authentication, thereby protecting against corruption, spoofing 
of RSVP messages, and replay. [RSVP-SEC-KEY] discusses key types and 
key provisioning methods, as well as their respective applicability 
to RSVP authentication. 


[RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms 
([RFC4302] [RFC4303]) and associated key provisioning methods for 


security protection of RSVP. This discussion applies to the 
protection of RSVP in the presence of RSVP proxies as defined in this 
document. 


A subset of RSVP messages are signaled with the IP router alert 
option ([RFC2113], [RFC2711]). Based on the current security 
concerns associated with the use of the IP router alert option, the 
applicability of RSVP (and therefore of the RSVP proxy approaches 
discussed in this document) is limited to controlled environments 
(i.e., environments where the security risks associated with the use 
of the IP router alert option are understood and protected against). 
The security aspects and common practices around the use of the 
current IP router alert option, and consequences of using the IP 
router alert option by applications such as RSVP, are discussed in 
detail in [RTR-ALERT]. 
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A number of additional security considerations apply to the use of 
RSVP proxies and are discussed below. 


With some RSVP proxy approaches, the RSVP proxy operates autonomously 
inside an RSVP router. This is the case for the Path-Triggered Proxy 
approaches defined in Section 4.1 and in Section 4.2, for the 
Inspection-Triggered Proxy approach defined in Section 4.3, for the 
STUN-Triggered Proxy approach defined in Section 4.4, and for the 
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper 
reservation operation assumes that the RSVP proxy can be trusted to 
behave correctly in order to control the RSVP reservation as required 
and expected by the end-systems. Since the basic RSVP operation 
already assumes a trust model where end-systems trust RSVP nodes to 
appropriately perform RSVP reservations, the use of an RSVP proxy 
that behaves autonomously within an RSVP router is not seen as 
introducing any significant additional security threat or as 
fundamentally modifying the RSVP trust model. 


With some RSVP proxy approaches, the RSVP proxy operates under the 
control of another entity. This is the case for the 

Application Entity-Controlled Proxy approach defined in Section 4.5 
and for the Policy Server-Controlled Proxy approach defined in 
Section 4.6. This introduces additional security risks since the 
entity controlling the RSVP proxy needs to be trusted for proper 
reservation operation and also introduces additional authentication 
and confidentiality requirements. The exact mechanisms to establish 
such trust, authentication, and confidentiality are beyond the scope 
of this document, but they may include security mechanisms inside the 
protocol used as the control interface between the RSVP proxy and the 
entity controlling it, as well as security mechanisms for all the 
interfaces involved in the reservation control chain (e.g., inside 
the application signaling protocol between the end-systems and the 
application entity, and, in the case of the Policy Server-Controlled 
Proxy approach, in the protocol between the application entity and 
the policy server). 


In some situations, the use of RSVP proxy to control reservations on 
behalf of end-systems may actually reduce the security risk (at least 
from the network operator viewpoint). This could be the case, for 
example, because the routers where the RSVP proxy functionality runs 
are less exposed to tampering than end-systems. Such a case is 
further discussed in Section 4 of [RFC5946]. This could also be the 
case because the use of RSVP proxy allows localization of RSVP 
operation within the boundaries of a given administrative domain 
(thus easily operating as a controlled environment) while the end-to- 
end flow path spans multiple administrative domains. 
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Appendix A. Use Cases for RSVP Proxies 


A.1.  RSVP-Based VoD Admission Control in Broadband Aggregation Networks 


As broadband services for residential customers are becoming more and 
more prevalent, next-generation aggregation networks are being 
deployed in order to aggregate traffic from broadband users (whether 
attached via Digital Subscriber Line technology, aka DSL; Fiber To 
The Home/Curb, aka FTTx; Cable; or other broadband access 


technology). Video on Demand (VoD) services, which may be offered to 
broadband users, present significant capacity planning challenges for 
the aggregation network for a number of reasons. First, each VoD 


stream requires significant dedicated sustained bandwidth (typically 
2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition 
TV). Secondly, the VoD codec algorithms are very sensitive to packet 
loss. Finally, the load resulting from such services is very hard to 
predict (e.g., it can vary quite suddenly with blockbuster titles 
made available as well as with promotional offerings). As a result, 
transport of VoD streams on the aggregation network usually translate 
into a strong requirement for admission control. The admission 
control solution protects the quality of established VoD sessions by 
rejecting the additional excessive session attempts during 
unpredictable peaks, during link or node failures, or a combination 
of those factors. 


RSVP can be used in the aggregation network for admission control of 
the VoD sessions. However, since customer premises equipment such as 
Set Top Boxes (STBs) (which behave as the receiver for VoD streams) 
often do not support RSVP, the last IP hop in the aggregation network 
can behave as an RSVP Receiver Proxy. This way, RSVP can be used 
between VoD pumps and the last IP hop in the aggregation network to 
perform accurate admission control of VoD streams over the resources 
set aside for VoD in the aggregation network (typically a certain 
percentage of the bandwidth of any link). As VoD streams are 
unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as 
described in Section 4.1) is all that is required in this use case. 


Figure 14 illustrates operation of RSVP-based admission control of 
VoD sessions in an aggregation network involving RSVP support on the 
VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop 
of the aggregation network. All the customer premises equipment 
remains RSVP-unaware. 
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/N VoD Application-level signaling (e.g., RTSP) 

Figure 14: VoD Use Case with Receiver Proxy 


In the case where the VoD pumps are not RSVP-capable, an 

Application Entity-Controlled Sender Proxy via the "RSVP over GRE" 
approach (as described in Section 4.5.1) can also be implemented on 
the VoD Controller or Session Resource Manager (SRM) devices 
typically involved in VoD deployments. Figure 15 illustrates 
operation of RSVP-based admission control of VoD sessions in an 
aggregation network involving such an Application Entity-Controlled 
Source Proxy combined with an RSVP Receiver Proxy on the last IP hop 
of the aggregation network. All the customer premises equipment, as 
well as the VoD pumps, remain RSVP-unaware. 
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////\ NoD SRM [NNNNNNNNNNA 
/ \ 
/ + \ 
/ | RSVP Sender | \ 
/ [Proxy Control| N 
/ [Sasa =a aes \ 
/ /=/ \ 
/ /=/ \ 
/ /=/ \ 
/ /=/ \ 

/ /=/ \ 
|---- | [xxxx xx | KKK KKK KKKKKKKK| | |--- 
| VoD|--|RSVP  |----*r*--*r*--|RSVP |--|DSLAM|^^^^|STB| -- TV 
[|Pump|  |Sender| *** xxx  |Receiver| |----- | |---| 
|---- | Proxy Proxy 

KKKKKK KKKKKKKK 
<a Aggregation Net > 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKD 


RSVP > 


SRM Systems Resource Manager 


KK ie 


*r* regular RSVP | Set Top Box 
AK EOUTÈT |---| 


***» VoD media flow 

==> segment of flow path protected by RSVP reservation 
/ VoD Application-level signaling (e.g., RTSP) 

/-/ GRE-tunneled RSVP (Path messages) 


Figure 15: VoD Use Case with Receiver Proxy 
and SRM-Based Sender Proxy 


The RSVP proxy entities specified in this document play a significant 
role here since they allow immediate deployment of an RSVP-based 
admission control solution for VoD without requiring any upgrade to 
the huge installed base of non-RSVP-capable customer premises 
equipment. In one mode described above, they also avoid upgrade of 
non-RSVP-capable VoD pumps. In turn, this means that the benefits of 
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on-path admission control can be offered to VoD services over 
broadband aggregation networks without network or VoD pump upgrade. 
Those include accurate bandwidth accounting regardless of topology 
(hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic 
adjustment to any change in topology (such as failure, routing 
change, additional links, etc.). 


A.2.  RSVP-Based Voice/Video Connection Admission Control (CAC) in 
Enterprise WAN 


More and more enterprises are migrating their telephony and 
videoconferencing applications onto IP. When doing so, there is a 
need for retaining admission control capabilities of existing TDM- 
based (Time-Division Multiplexing) systems to ensure the QoS of these 
applications is maintained even when transiting through the 
enterprise's Wide Area Network (WAN). Since many of the endpoints 
already deployed (such as IP phones or videoconferencing terminals) 
are not RSVP-capable, RSVP proxy approaches are very useful: they 
allow deployment of an RSVP-based admission control solution over the 
WAN without requiring upgrade of the existing terminals. 


A common deployment architecture for such environments relies on the 
Application Entity-Controlled Proxy approach as defined in 

Section 4.5. Routers sitting at the edges of the WAN are naturally 
"on-path" for all inter-campus calls (or sessions) and behave as RSVP 
proxies. The RSVP proxies establish, maintain, and tear down RSVP 
reservations over the WAN segment for the calls (or sessions) under 
the control of the SIP server/proxy. The SIP server/proxy 
synchronizes the RSVP reservation status with the status of end-to- 
end calls. For example, the called IP phone will only be instructed 
to play a ring tone if the RSVP reservation over the corresponding 
WAN segment has been successfully established. 


This architecture allowing RSVP-based admission control of voice and 
video on the enterprise WAN is illustrated in Figure 16. 
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L1 440011111111| SIP [AAA 
/ Server/ \ 
/ Proxy | X 
/ |--------- | \ 
/ // \\ \ 
/ // \\ \ 
/ // \\ \ 
/ // \\ \ 
/ // \\ \ 
| pP | | cese | * KK *ckok | oce | | eee | 
| IP |------ | Media |---*r*---*r*---| Media  |------- | IP | 
| Phone | | Relay | KER Ato | Relay | | Phone | 
--=-- oa | + | — 
| RSVP | | RSVP | 
Proxy Proxy 
KKKKKKKK KKKKKKKK 
«--campus---» «--campus---» 
network network 


UKCkCKkCkCk ck ckck ck ck ck kck mo QUKCk kck ck ck k ck ck ck k ck ck ck ck ck ck ck ck ck ck kk o QUkCk Ck k ck ck ck ck ck k kk kk 


< RSVP > 
*kk 
*y Regular RSVP router 
*kk 


«***» media flow 


<==> segment of flow path protected by RSVP reservation 


/N SIP signaling 
// control interface between the SIP server/proxy and 
RSVP proxy 


Figure 16: CAC on Enterprise WAN Use Case 
A.3. RSVP Proxies for Mobile Access Networks 
Mobile access networks are increasingly based on IP technology. This 


implies that, on the network layer, all traffic, both traditional 
data and streamed data like audio or video, is transmitted as 
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packets.  Increasingly popular multimedia applications would benefit 
from better than best-effort service from the network, a forwarding 
service with strict Quality of Service (QoS) with guaranteed minimum 
bandwidth and bounded delay. Other applications, such as electronic 
commerce, network control and management, and remote-login 
applications, would also benefit from a differentiated treatment. 


The IETF has two main models for providing differentiated treatment 
of packets in routers. The Integrated Services (IntServ) model 
[RFC1633], together with the Resource Reservation Protocol (RSVP) 
[RFC2205], [RFC2210], [RFC2961] provides per-flow guaranteed end-to- 
end transmission service. The Differentiated Services (Diffserv) 
framework [RFC2475] provides non-signaled flow differentiation that 
usually provides, but does not guarantee, proper transmission 
service. 


However, these architectures have potential weaknesses for deployment 
in Mobile Access Networks. For example, RSVP requires support from 
both communication endpoints, and the protocol may have potential 
performance issues in mobile environments. Diffserv can only provide 
statistical guarantees and is not well suited for dynamic 
environments. 


Let us consider a scenario, where a fixed network correspondent node 
(CN) would be sending a multimedia stream to an end host behind a 
wireless link. If the correspondent node does not support RSVP, it 
cannot signal its traffic characteristics to the network and request 
specific forwarding services. Likewise, if the correspondent node is 
not able to mark its traffic with a proper Differentiated Services 
codepoint (DSCP) to trigger service differentiation, the multimedia 
stream will get only best-effort service, which may result in poor 
visual and audio quality in the receiving application. Even if the 
connecting wired network is over-provisioned, an end host would still 
benefit from local resource reservations, especially in wireless 
access networks, where the bottleneck resource is most probably the 
wireless link. 


RSVP proxies would be a very beneficial solution to this problem. It 
would allow distinguishing local network reservations from the end- 
to-end reservations. The end host does not need to know the access 
network topology or the nodes that will reserve the local resources. 
The access network would do resource reservations for both incoming 
and outgoing flows based on certain criteria, e.g., filters based on 
application protocols. Another option is that the mobile end host 
makes an explicit reservation that identifies the intention, and the 
access network will find the correct local access network node(s) to 
respond to the reservation.  RSVP proxies would, thus, allow resource 
reservation over the segment that is the most likely bottleneck, the 
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wireless link. If the wireless access network uses a local mobility 
management mechanism, where the IP address of the mobile node does 
not change during handover, RSVP reservations would follow the mobile 
node movement. 


A.4.  RSVP Proxies for Reservations in the Presence of IPsec Gateways 


[RFC4923] discusses how resource reservation can be supported end-to- 
end in a nested VPN environment. At each VPN level, VPN routers 
behave as [RFC4301] security gateways between a plaintext domain and 
a ciphertext domain. To achieve end-to-end resource reservation, the 
VPN routers process RSVP signaling on the plaintext side, perform 
aggregation of plaintext reservations, and maintain the corresponding 
aggregate RSVP reservations on the ciphertext side. Each aggregate 
reservation is established on behalf of multiple encrypted end-to-end 
sessions sharing the same ingress and egress VPN routers. These 
aggregate reservations can be as specified in [RFC3175] or [RFC4860]. 


Section 3 of [RFC4923] discusses the necessary data flows within a 
VPN router to achieve the behavior described in the previous 
paragraph. Two mechanisms are described to achieve such data flows. 
Section 3.1 presents the case where the VPN router carries data 
across the cryptographic boundary. Section 3.2 discusses the case 
where the VPN router uses a Network Guard. 


Where such mechanisms are not supported by the VPN routers, the 
approach for end-to-end reservations presented in [RFC4923] cannot be 
deployed. An alternative approach to support resource reservations 
within the ciphertext core is to use the Application Entity- 
Controlled Proxy approach (as defined in Section 4.5) in the 
following way: 


o the RSVP proxies are located inside the ciphertext domain and use 
aggregate RSVP reservations. 


o the application entity exchange application-level signaling with 
the end-systems in the plaintext domain. 


o the application entity controls the RSVP proxies in the ciphertext 
domain via an RSVP proxy control interface. 


This is illustrated in Figure 17 in the case where the application is 
SIP-based multimedia communications. 
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=====> =====> 
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|****| RSVP-capable |****| RSVP-capable AR 
S Sender R Receiver *r* regular RSVP 
KKKK KkKKK KkK*k router 
| IPsec | IPsec security gateway 
| cw | 


ARSVP Aggregate RSVP 

***» media flow 

==> segment of flow path protected by RSVP reservation 
/ \ SIP signaling 


Network management interface between SIP server/proxy 
and IPsec security gateway 


// control interface between SIP server/proxy and ARSVP proxy 
PT Plaintext network 
CT Ciphertext network 


Figure 17: RSVP Proxies for Reservations in the Presence of 
IPsec Gateways 
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Where the sender and receiver are RSVP-capable, they may also use 
RSVP signaling. This achieves resource reservation on the plaintext 
segments of the end-to-end, i.e., 


o from the sender to the ingress IPsec gateway, and 
o from the egress IPsec gateway to the receiver. 


In this use case, because the VPN routers do not support any RSVP- 
specific mechanism, the end-to-end RSVP signaling is effectively 
hidden by the IPsec gateways on the ciphertext segment of the end-to- 
end path. 


As with the Application Entity-Controlled Proxy approach (defined in 
Section 4.5), the solution here for synchronizing RSVP signaling with 
application-level signaling is to rely on an application-level 
Signaling device that controls an on-path RSVP proxy function. 
However, in this use case, the RSVP proxies are a component of a 
ciphertext network where all user (bearer) traffic is IPsec 
encrypted. This has a number of implications, including the 


following: 

1. encrypted flows cannot be identified in the ciphertext domain so 
that network nodes can only classify traffic based on IP address 
and Differentiated Services codepoints (DSCPs). As a result, 


only aggregate RSVP reservations (such as those specified in 
[RFC3175] or [RFC4860]) can be used. This is similar to 
[RFC4923]. 


2. Determining the RSVP Sender Proxy and RSVP Receiver Proxy to be 
used for aggregation of a given flow from sender to receiver 
creates a number of challenges. Details on how this may be 
achieved are beyond the scope of this document. We observe that, 
as illustrated in Figure 17, this may be facilitated by a network 
management interface between the application entity and the IPsec 
gateways. For example, this interface may be used by the 
application entity to obtain information about which IPsec 
gateway is on the path of a given end-to-end flow. Then, the 
application entity may maintain awareness of which RSVP proxy is 
on the ciphertext path between a given pair of IPsec gateways. 
How such awareness is achieved is beyond the scope of this 
document. We simply observe that such awareness can be easily 
achieved through simple configuration in the particular case 
where a single (physical or logical) RSVP proxy is fronting a 
given IPsec gateway. We also observe that when awareness of the 
RSVP Receiver Proxy for a particular egress IPsec gateway (or 
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end-to-end flow) is not available, the aggregate reservation may 
be signaled by the RSVP Sender Proxy to the destination address 
of the egress IPsec gateway and then proxied by the RSVP Receiver 
Proxy. 


Different flavors of operations are possible in terms of aggregate 
reservation sizing. For example, the application entity can initiate 
an aggregate reservation of fixed size a priori and then simply keep 
count of the bandwidth used by sessions and reject sessions that 
would result in excess usage of an aggregate reservation. The 
application entity could also re-size the aggregate reservations on a 
session-by-session basis. Alternatively, the application entity 
could re-size the aggregate reservations in step increments typically 
corresponding to the bandwidth requirement of multiple sessions. 


Le Faucheur, et al. Informational [Page 49] 


RFC 5945 RSVP Proxy Approaches October 2010 


Authors' Addresses 


Francois Le Faucheur 

Cisco Systems 

Greenside, 400 Avenue de Roumanille 
Sophia Antipolis 06410 

France 


Phone: 433 4 97 23 26 19 
EMail: flefauch@cisco.com 


Jukka Manner 

Aalto University 

Department of Communications and Networking (Comnet) 
P.O. Box 13000 

FIN-00076 Aalto 

Finland 


Phone: +358 9 470 22481 
EMail: jukka.manner@tkk.fi 
URI: http://www.netlab.tkk.fi/^jmanner/ 


Dan Wing 

Cisco Systems 

170 West Tasman Drive 
San Jose, CA 95134 
United States 


EMail: dwing8cisco.com 


Allan Guillou 

SFR 

40-42 Quai du Point du Jour 
Boulogne-Billancourt 92659 
France 


EMail: allan.guillou@sfr.com 


Le Faucheur, et al. Informational [Page 50] 


